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ABSTRACT 

Hypertext is an exciting concept, but designing and developing hypertext 
applications of practical scale is hard. "Hypertext engineers" must overcome seven 
problems to make a project feasible and successful. These are (1) Developing realistic 
expectations in the face of hypertext hype; (2) Assembling a multidisciplinary project 
team; (3) Establishing and following design guidelines; (4) Dealing with installed base 
constraints; (5) Obtaining usable source files; (5) Finding appropriate software 
technology and methods; and (6) Overcoming legal uncertainties about intellectual 
property concerns. 


INTRODUCTION 

The excitement in the technical community and the popular press is rapidly 
inspiring others to pursue the vision of hypertext as a means to combine text, graphics, 
voice, and other media to make information more accessible, usable, and entertaining. 
Nevertheless, the novelty and immaturity of "hypertext engineering" as a discipline 
causes many projects to fall short of these goals. Elsewhere I have emphasized some 
of the challenging design issues that must be overcome "to make the hypertext vision 
happen" (Glushko, 1990b). In this paper I take a broader view to include management 
and non-technical factors to expand the list to seven ways in which hypertext projects 
fail. Not all of these problems are specific to hypertext projects, but together these 
seven issues conspire to make hypertext applications hard to design, develop, and 
deploy successfully. 


A Composite Case Study 

Attracted by the excitement about hypertext, Company C decides that links and 
navigation features will bring enhanced usability to a problem that has traditionally been 
handled in a database or document archive. Since it is the first hypertext project in 
Company C, all of the most talented and ambitious researchers and developers find 
their way onto the project. No one keeps track of how much time and effort goes into it, 
but after a few months a carefully hand-crafted demonstration system or prototype 
emerges using "Hyper-X." Hyper-X is a highly-touted program that everyone is talking 
and reading about as a revolutionary software advance. 

The prototype system is flashy and compelling on the 19-inch workstation screen. 
It contains only a tiny amount of the information contained in the application it is 
intended to replace, but even a casual observer is impressed by how usable and 
appealing it looks. The colors, graphics scanned from documents and books, 
animation, and sound effects come together seamlessly to create a multimedia proof-of- 

concept. B ' 

The Vice President of Company C compares the prototype with the onginal text- 
based system and declares the Hyper-X version a smashing success. All that remains 
is to "scale it up" by converting the remainder of the information to hypertext. 


SEVEN WAYS TO FAIL 

y°^j nter P ret this case study so far might depend on where vou are in vnur 
project, or whether you are part of the prototype team or a member of the toam taeVoH 
to scale it up. But the stage is now set for duster™ the scions hat fo®tow Tanatze 
the seven ways in which the project can fail based on the composite case study X 


Unrealistic Expectations About Scale and Readiness 

!♦ ♦ Wh ?, n L he toll-scale development project begins, the organization tasked to carrv 
it out usually has unrealistic expectations about how hard it is and about the capabilities 
and resources needed to do it. Demonstration projects often bring togeth^he test 
people with ample resources and whose efforts benefit from ad hoc inter-organizational 
cooperation because of the novelty of hypertext. Many demonstration projects 
succeed by using methods and tools that are impossible to scale up (Alschuler P 1989) 
Often the demonstration project uses an off-the-shelf software package that provides 

kw !E!V«2v apa ?!S^ r the P® r f ormance to deliver the bulk of information now managed 
thl th 5 trad itional database or file system. Worse, the information examples and links in 
the demonstration project may nave been carefully hand-crafted, an unworkable 

.fP. r °J c c , h ^ aSy , St9m sev ! ral orders of magnitude larger. An obsessive focus on "how 
rt looks often drives out senous consideration of "how it has to work " If a 
demonstration project takes three months to convert five articles from an encyclopedia 
into an interactive hypermedia form, how long will it take to convert a thousand aiScles 
using the same techniques? Automatic, semiautomatic, or template-based techniques 
are the only realistic option for large conversion projects, but these are almost never 

SSif?ne dUnn9 the ,n,tia P rotot yP' n g effort « wh ‘cn usually focuses on user interface 
co ncerns. 

. Overtime, organizations will acquire an experience base that allows them to 

rn^mofnimo ^ 0S /°K lar9e " sc ^ le pro i ects that in volve toxt and hypertext. But in 
the meantime it is better to be conservative. /K 


Missing Skills on Design and Development Team 


Organizations considering a hypertext project usually have ample software 
design and development skills available. However, nypertext projects may require for at 
jeajabenett from) a broader mix of skills. Appropriate skills i^'h^rte^oiS team 


* Software designers 

* User interface designers 

* Usability testers and potential users 

* Technical writers ana editors 

* Indexers 

* Database designers 


Hypermedia projects can require still other talents, including graphic artists and 
people who understand how to integrate multiple media, sometimes called "art 
dtrectore. For conversion projects, the participation of the author or editor of the 
origina! information can be invaluable in understanding the presentation conventions of 
the existing format. If neither is available, the project should allow additional time to 



understand the design and design rationale of the existing information. Likewise, the 
people who run the plant, repair the airplanes, or otherwise are expert in the application 
area must be involved, or the project runs the risk of building a carefully-designed user 
interface to the wrong information. 

Few organizations or individuals have expertise in more than a few of these 
areas. Even if the needed mix of skills for a project organization can be assembled by 
matrix management or by bringing in appropriate consultants, making such an 
interdisciplinary team work effectively together is no small challenge. 


Few Published Case Studies or Design Guidelines 


Because hypertext is a relatively new design field, there are few detailed 
published case studies or design guidelines that designers can readily use. Published 
reports about hypertext are not representative, typically biased toward small-scale 
demonstrations or research projects. While hypertext applications of practical scale 
have been successfully designed and implemented, in general such projects are not 
documented in the literature because of resource constraints m development 
organizations, propriatary considarations, or bacausa thay ara classifiad for sacunty 


reasons. 

While there is a growing body of empirical research evaluating particular 
hypertext systems or specific design options, this work does not usually generalize well. 
In addition, what formal experiments have been able to establish is that most of the 
design choices, when considered in isolation, have only small percentage impacts on 
system usability (Nielsen, 1989). To complicate matters, sometimes small changes in 
the user's task or the structure of the hypertext can lead to conflicting answers about the 
relative merit of design features (Wright & Lickorish, 1990). Individual differences in 
users especially motivational differences, and the effects of different tasks seem to 
have major effects on system usability. Yet who the users are and the tasks they want 
to carry out are often not something the hypertext system designer can control. 

However designers of hypertext systems can take steps to ensure that their 
systems are acceptable and effective for their users. Whije empirically validated design 
guidelines remain some way off, design methodologies for hypertext are being 
proposed; the most comprehensive of these is that of Perlman (Perlman, 1989). 


Installed Base Constraints 

Hypertext demonstration projects are often done in research organizations that 
have advanced technology, including workstations and high-resolution 19-inch monitors. 
HyperCard on the Macintosh computer is also a very popular environment for 

demonsttato^project^ for w h 0m full-scale versions of these demonstration 

systems must be targeted often work with an older or different installed base of 
computing equipment. This installed base may consist predominantly of IBM AT- 
compatible processors with small display screens having limited graphics resolution. 

This situation often poses a dilemma for hypertext projects. Advanced 
technology may be needed to demonstrate the benefits of hypertext capabihties, but he 
presentation of these capabilities in the demonstration projects exc eeds _what t the 
installed base will support. It is essential that the funding or marketing organization 
promoting the project know the costs and tradeoffs implied by 
alternatives. Which is more successful, a project that uses iess-advanced t^hnology to 
create lower expectations that can be met, or a project that uses state-of-the art 



^SSsSbSt f^^URsas* — 

that the user imeria^ran b^enhm^ m ttei ng^i, 9 - 01 ,he hy P er,e,rt system so 
constraints in processira power for ^ta^ hJS^- 1 ^ permi !. s *■ Temporary 
exploiting space vs. time tradeoffs in iSISS destanfTr^™!! be ove : come »>/ 
can be pre-computed and stored on a C^D-ROM instfadof computed ?n rea'l' tim”" maPS 


Poor Quality or Availability of Source Files 

« ~S7«rcsr»^r rjjBfss sfssarras 

* *u ? ne common limitation derives from the languaqe with which the winitai w 0re inn 
that specifies the logical structure of the document rather than its presentation 9 90 

<* n J« 

°rrect T p n ,,ro„ S es «m 198% (Cushman 

hypertext projects carefully investigate source quality and Si^^h2in2^S2Si-i- 
to a project schedule. A single J^nSTS^ 

L a JB»m? CUment ° r d0 5, u ?® nt collection (such as the completed of manuate for a°aml 
system) was assembled from parts created by different verSore or" ufaco^rSSf 

a » n SS rmay have P rovide ? documents in a different sourc^forJn wdoaSSSS 
o vanou ® sourca ,orma ts P it is generally more cost-effective to have a 
!f 1 '^*P a l5L text conversion service transform all of them to a common format than to Ssf 
project software resources to carry out the conversion. 

ortu * na !t 0 5(’ f s th0 " neutra ' data" specifications being developed as Dart of cal < 5 
(Department of Defense, 1985) and IMI$ (Thomas & Clay l 988) tScf hoW buildinn 
hypertext applications on existing information will become significantly easier ' 9 

AkmwhonP th 8Xt iw ' r 5^ s V hose a PP ,ication involves periodic publication of text created 

ssswsf «BBSJsna s zsz, wSS 

kZ7»™clin'vV^oS r ^S' 01 hyper,9xt conv9reion hy 9nabli "9 the development of 


Lack of Appropriate Software Tools 

anH off-the-shelf hypertext software is oriented toward creating new hypertexts 

?990a- Cl!i<Xkn St iQQnh? r c f ? nvert,n ? existing documents (Alschuler, 1989; Glushko 
1990a, Glushko, 1 990b). Demonstration projects often use this software to create 

t 5 0 l00k and feel of a full-scale implementation, and it often cornes 

^bili^fVpro^ert 0 d,SCOV0r fundamantal limitations in the software that jeopardize the 


It may be worth waiting for the next generation of hypertext software that directly 
supports conversion. The CALS initiative has prompted many vendors to enter this 
market, and the tools are expected to improve rapidly (Smithmidford, 1989). 
Alternatively, some database programs or expert system shells may better support 
hypertext features than programs that call themselves hypertext. 

If off-the-shelf software must be used for a hypertext project, it is imperative that 
any demonstration or proof-of-concept phase carefully address pragmatic issues of 
scaling up. These include both capacity concerns -- can the program manage 
significantly larger amounts of information with acceptable performance -- and resource 
concerns - does the program imply or impose design methods for defining units, links, 
or other features that are infeasible when applied on a large scale (Glushko, 1990a, 
1990b)? 


Legal Uncertainties 

In recent years there has been a rash of "look and feel" copyright infringement 
lawsuits and similar claims for software patents. These legal controversies have arisen 
because software has been defined both as a kind of "literary work," which makes it 
copyrightable, and as a kind of machine or method of operating one, which makes it 
patentable. While these legal analogies may be wrona and may someday be corrected 
by a new intellectual property law that recognizes the special character of software 
(Samuelson, 1989b), today software designers and developers are faced with chaos, 

uncertainty, and legal action. . . 

As unclear as the situation is for software in general, the novel character of 
hypertext and hypermedia software raises still more complexities for intellectual property 
law. For example, if copyright law has different rules for "literary works," "audiovisual 
works " "sound recordings," and "pictorial works," into what legal category does an 
interactive hypermedia encyclopedia or a talking book fall? Are new links or notes in a 
hypertext system considered "derivative works" under copyright law? These and other- 
issues are not just legal curiosities; they will have considerable impact on the legal 
protection available and hence the economic viability of hypermedia systems. 

One aspect of copyright infringement that confronts hypermedia designers and 
developers is clear and well-known, but new technology has made it easier to break the 
law OCR, scanners, digital samplers and video "frame grabbers" are among the wide 
variety of technology that makes it possible to copy almost anything and incorporate it 
into a hypermedia system. But having the technology does not imply the nght, and a 
sure way to invite a lawsuit is to assure© that it doos. It is not a coincidence that many 
hypertext applications have used government documents like standards and regulations 

that are free of copyright restrictions. . ^ 4 . . . . . . ^ 

The best defense against a copynght infringement claim is to be able to prove 
independent development, so keeping careful documentation of design decisions is 
essential. In addition, designs based on experiments or evaluations give the design a 
"functional" character that narrows the scope of copyright infringement claims. It is best 
to follow the golden rule when designing a system: Borrow from others no more than 
you would have there borrow from you. An alternative formulation of this pnnciple can 
be found in a well-reasoned paper that presents b<?th sides of the look-and-feel debate: 
Let he who has never borrowed cast the first lawsuit (Samuelson, 1989a). 


SUMMARY 

Hypertext is an attractive vision, but practical hypertext applications are hard to 
build. Disciplined approaches to analyzing information, identifying constraints in its 
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